[PFA 2/n] Support PFA functionality #20848

arnaud-lb · 2026-01-06T12:02:28Z

RFC: https://wiki.php.net/rfc/partial_function_application_v2

This follows #20717. This implements most of the RFC, except PFAs in constant expressions, and some optimization.

I wanted to split this PR more, but I didn't find a way to achieve this that makes sense.

A partial application is compiled to the usual sequence of function call
opcodes (INIT_FCALL, SEND_VAR, etc), but the sequence ends with a
CALLABLE_CONVERT_PARTIAL opcode instead of DO_FCALL, similarly to
first class callables. Placeholders are compiled to SEND_PLACEHOLDER opcodes:

$f = f($a, ?)

0001 INIT_FCALL f
0002 SEND_VAR CV($a)
0003 SEND_PLACEHOLDER
0004 CV($f) = CALLABLE_CONVERT_PARTIAL

SEND_PLACEHOLDER sets the argument slot type to _IS_PLACEHOLDER.

CALLABLE_CONVERT_PARTIAL uses the information available on the stack to
create a Closure and return it, consuming the stack frame in the process
like an internal function call.

We create the Closure by generating the relevant AST and compiling it to an
op_array.

The op_array is cached in the Opcache SHM and inline caches. The SHM key is prefixed with pfa:// to avoid any collision with actual files. When Opcache is disabled, we cache PFA op_arrays a global hash table. This is mainly useful for polymorphic PFAs, as the inline cache stores only a single entry.

TimWolla

Looked at 43/143 files with a mix of tests and C code.

Zend/zend_execute.c

TimWolla · 2026-01-07T11:23:04Z

Zend/tests/partial_application/errors_004.phpt

+
+?>
+--EXPECTF--
+Fatal error: Uncaught ArgumentCountError: f(): Argument #2 ($b) not passed in %s:6


Is it possible to improve the error message here to make it clear that this is happening during partial application?

This is not specific to partials: https://3v4l.org/biQNc

TimWolla · 2026-01-07T11:25:06Z

Zend/tests/partial_application/errors_005.phpt

+
+?>
+--EXPECT--
+ArgumentCountError: Closure::__invoke(): Argument #3 ($c) must be passed explicitly, because the default value is not known


As a user the error message reads odd, because stating that the default value is “unknown” implies that it is unclear whether there is one. If this is a technical restriction this should be rephrased to something like “cannot be determined for Closures” or something like that.

This error is not specific to partials or Closures: https://3v4l.org/Kl9M1

It is thrown when a parameter with position n < func_num_args() is not specified, and has a default value of UNKNOWN, like here:

php-src/ext/standard/basic_functions.stub.php

Line 1689 in 643cf62

function array_keys(array $array, mixed $filter_value = UNKNOWN, bool $strict = false): array {}

The reason it can happen is that functions assume that all arguments bellow func_num_args() are specified, but due to named args it's not always the case. So the engine fills the unspecified args bellow func_num_args() with their default value, but that's not possible with UNKNOWN.

Closure::__invoke() is a special case of this, as the default value is always unknown for this function (this affects only calling __invoke() explicitly).

I'm realizing that in the context of PFAs, we could probably avoid this by making placeholders without a default value required. I can look at this in a separate PR after this one.

Zend/tests/partial_application/magic_003.phpt

Zend/tests/partial_application/rfc_examples_incompatible_functions.phpt

Zend/zend_ast.c

TimWolla

74/144

Zend/tests/partial_application/non_dynamic_call_funcs.phpt

TimWolla · 2026-01-08T08:31:08Z

Zend/tests/partial_application/recorded_warnings.phpt

+
+Deprecated: Using "_" as a type name is deprecated since 8.4 in %s on line 5


I think this error message being emitted here is not great, because this is not actionable by the user who have written the PFA call (it can only be fixed by the author of the function being called).

Indeed.

Possible alternative ways to handle these errors:

Prefix errors with "During compilation of partial application:"

Discard non-fatal errors emitted during compilation of PFAs

Implement workarounds to avoid emitting any error

The second one seems to be the most sensible, as the errors are actually related to the function being called.

Zend/tests/partial_application/references_001.phpt

Zend/tests/partial_application/references_002.phpt

Zend/tests/partial_application/rfc_examples_debug.phpt

Zend/tests/partial_application/statics_002.phpt

Zend/tests/partial_application/statics_003.phpt

Zend/tests/partial_application/variation_invoke_001.phpt

Zend/tests/partial_application/variation_ex_001.phpt

TimWolla · 2026-01-08T08:41:12Z

Zend/tests/partial_application/variation_scope_001.phpt

I can't imagine what else than Foo would be returned for get_called_class(). Should this test involve inheritance?

Yes, this is just testing basic functionality. That get_called_class() works as expected is obvious with the current implementation, but may not have been with the previous one where the call was made in a more custom way.

RFC: https://wiki.php.net/rfc/partial_function_application_v2 Co-authored-by: Joe Watkins <[email protected]>

github-actions bot added Category: Build System Category: Engine Extension: opcache Category: Optimizer ABI break labels Jan 6, 2026

TimWolla added the RFC label Jan 6, 2026

TimWolla reviewed Jan 7, 2026

View reviewed changes

arnaud-lb mentioned this pull request Jan 7, 2026

Introduce zend_ast_call_get_args() #20859

Merged

TimWolla reviewed Jan 8, 2026

View reviewed changes

arnaud-lb and others added 15 commits January 8, 2026 12:30

Partial application

5efd54c

RFC: https://wiki.php.net/rfc/partial_function_application_v2 Co-authored-by: Joe Watkins <[email protected]>

Remove unnecessary change

0849041

Skip preload test on Windows

d14ca74

Comments

1617a73

Improve type coherency

98e64d5

Clarify

6819628

Useless memset

0326e5d

Move include

5399547

Rename tests

ccca2eb

Fix test

cbcdbc1

Better type

96c4a78

Generated file

ec25cd6

Consistency

029481c

Fix test name

3fc7f7f

Improve tests

2cf2ae1

arnaud-lb force-pushed the partials-v2-gen branch from 0b7a4a5 to 2cf2ae1 Compare January 8, 2026 11:32

arnaud-lb marked this pull request as ready for review January 13, 2026 15:13

arnaud-lb requested a review from dstogov as a code owner January 13, 2026 15:13


		Deprecated: Using "_" as a type name is deprecated since 8.4 in %s on line 5

[PFA 2/n] Support PFA functionality #20848

Are you sure you want to change the base?

[PFA 2/n] Support PFA functionality #20848

Conversation

arnaud-lb commented Jan 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TimWolla left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

TimWolla Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

arnaud-lb Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

TimWolla Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

arnaud-lb Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

TimWolla left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

TimWolla Jan 8, 2026

Choose a reason for hiding this comment

Uh oh!

arnaud-lb Jan 8, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

TimWolla Jan 8, 2026

Choose a reason for hiding this comment

Uh oh!

arnaud-lb Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

arnaud-lb commented Jan 6, 2026 •

edited

Loading

arnaud-lb Jan 8, 2026 •

edited

Loading